Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000119_owner-urn-ietf _Tue Oct 29 19:02:48 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA21586 for urn-ietf-out; Tue, 29 Oct 1996 19:02:48 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA21579 for <[e-mail]>; Tue, 29 Oct 1996 19:02:44 -0500
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA06918  (mail destined for [e-mail]); Tue, 29 Oct 96 19:02:34 -0500
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA05714; Tue, 29 Oct 1996 19:02:31 -0500
Date: Tue, 29 Oct 1996 19:02:31 -0500
Message-Id: <[e-mail]>
From: "Karen R. Sollins" <[e-mail]>
To: [e-mail]
Subject: [URN] some comments
Sender: [e-mail]
Precedence: bulk
Reply-To: "Karen R. Sollins" <[e-mail]>
Errors-To: [e-mail]

Not being a big fan of character set wars, I've sat by the sidelines
for a while.  I just reread all the messages to this list for the last
couple of weeks, trying to pick out places where there may be deeper
issues.  So, I have here a small list of somewhat disconnected
comments and questions.  For some of you this may not get to the heart
of the problems - my apologies.

Most of the discussion has centered around the URN syntex draft
written by Ryan Moats, so I will comment on that subject first.

1) There were a couple of almost parenthetical comments about the
NAPTR proposal that made me worry.  It is important that we all agree
that a URN syntax is independent of the NAPTR or any other URN
resolution proposal.  If we find that there are decisions that we all
agree are important for URN syntax, for which we find that the NAPTR
proposal is ill-equipped to deal (e.g. the relationship between
character sets and regular expressions) then we should NOT remove
those from the syntax document, but rather modify the NAPTR proposal.

2) About "urn:", I don't know whether I come from the other
"religious" viewpoint, but unless we have additional requirements and
mechanisms in place, I think it would be a really bad idea to make the
"urn:" optional.  Let's look at a few points here:

a) I don't believe that there is anything in the URL or URN
requirements documents (or any other RFCs) that states that prefixes
for URNs (without the "urn:") and URLs cannot be the same.

b) Given a random string (say foo://opaque_string) in some specific
situation, something needs to decide what it means and what to do with
it.  If the string is a URN it identifies a resource, while, if it is
a URL it identifies a location (in other words, it identifies an
abstraction from the perspective of a transport protocol, in fact, the
"foo" transport protocol).  So, now, without any specification of
urn-hood or url-hood, who makes a decision and how?

c) Consider how one might build applications, with respect to URNs
(it's too late for URLs to solve this problem).  Suppose five new
kinds of URNs are defined and five new kinds of URLs are defined.  The
application starts seeing strings with these ten new prefixes.  Now
the applications must have some mechanism for dealing with all these
new things.  So, assume it makes some decision, perhaps to send all
unidentifiable strings to a proxy for URNs.  This is something that
acts a front end for URN resolution.  For some large number of the
requests, the resolution will fail because truthfully, they were URLs.
Things could just as well have gone the other way if it was assumed
that the new strings are all URLs.  Some decision must be made one way
or the other.  The other alternative to the proxy is that the
application or some additional level of proxying does the
demultiplexing and is kept up to date with new kinds of URNs and
URLs.  If the answer is that the application must do it, then new
versions of every application using URNs must be distributed.  If the
answer is that there is a second level of proxying, we have now made
it take even longer to get an answer, by including another network
transit to the time to respond.

So, although I don't believe it is absolutely necessary, I do believe
that, first, if we don't require the "urn:" prefix we MUST document in
an RFC that URN and URL prefixes come from the same namespace and do
not overlap, and, second, if we do that, we understand that we are
potentially increasing the work to achieve new URN and URL resolution
activities.


3) About those character set discussions, perhaps we should step back
a little.  If I'm understanding the issues (and I certainly don't
claim to be an expert on character set issues), it seems to me that
the bottom line issue is that the thing to be avoided is false
positives when looking at equality or equivalence of URNs.  The
problem arises when something concludes that two URNs, once
transcoded, transliterated, or whatever, are identifying the same
resource, when they were intended to identify different ones.  False
negatives in this situation may cause additional work, additional
network traffic, and/or additional cost in other dimensions, but not
incorrect behavior.  It is the incorrect behavior that must take the
front seat.  With that in place, clearly the more effective we can be
at avoiding false negatives the nicer it is, but that must be
secondary.

It seems to me if one keeps this in mind, some of the concerns that
were brought up may fall into place a little more easily.  Such
questions as two encodings for "A grave" take a backseat to making
sure that the two encodings do not to get mapped into one, when in
some namespace they are considered distinct, thus allowing for
differentiation among resources.

***

Now, my one other comment relates to an earlier topic - security.  I
am in complete agreement with Ron (and whoever else) who said that
security (and let's make sure we include integrity of the information
in "security") that no one (user or publisher) should be required to
support security and integrity.  But...if the infrastructure
supporting URN resolution (which IS the topic of discussion for this
WG) is to be able to provide security and integrity for anyone, there
may be some requirements it will place on its clients (users and
publishers).  I would like to be confident that we are all in
agreement about the following: in the case where there are security
measures that must be in place within the infrastructure in order to
provide security (at some agreed upon level) to those who want it,
even if that imposes some security requirements on those who don't
want it, that the choice of having the security mechanisms in place
will take precedence over not have the mechanisms.  Of course, within
that constraint, wherever security isolation can be provided, security
mechanisms should NOT be required.

            Cheers,
            Karen


___________________________________________________________________
Karen R. Sollins                [e-mail]
Research Scientist                Phone: [phone]
M.I.T. Laboratory for Computer Science        Fax:   [phone]
545 Technology Square
Cambridge, MA 02139